How much analysis do you really need to do?

Howard Podeswa — Sun, 03 May 2009 04:21:00 GMT

As a BA, one of the central guiding principles for me has always been, "If it isn't going to make a difference to the outcome, don't do it." Yet I see a lot of confusion amongst BAs about how much analysis to do on a given project. Are structural models (class diagrams and ERDs) always worth doing or are they a waste of time? How much detail should you put into the user requirements? Obviously, blindly creating documentation without understanding its value - or if it even has any value - is not useful. The problem is when to do what. I thought this would be the perfect forum to toss out the question: How much analysis do you really need to do? I invite all responses – pro and con, cool and heated.

My real aim here is to generate discussion, not to be proscriptive. To get the discussion started, I'll start with some general guidance I’ve found useful.

The degree of documentation and analysis required for a project depends on a number of factors, including the lifecycle approach being used on the project, the size of the project, the type of solution being contemplated (in-house or vendor solution), and the risk involved.

There are two broad categories of lifecycles used on projects: definitive lifecycles - which are well-defined processes – and empirical processes, which are less defined. Projects managed using definitive lifecycles will require more documentation; those using en empirical lifecycle will require less. For example, while in a definitive lifecycle you might produce complete user requirements – expressed, for example, as use-case specifications, with an empirical lifecycle this would be of little value, since the requirements are constantly in a state of flux. On the other hand, even on an empirical project, there is still a need to list (if not completely describe) user tasks (use-cases) early on so that the effort required for and cost of the project can be estimated.

With respect to size – the larger the project, the greater the need for documentation. The team is bigger, the problem is more complex and more dollars are at stake – all factors favouring heavy documentation.

Solution type is another important factor. In-house solutions favour more documentation; vendor-supplied off-the-shelf solutions favour less documentation. Business rules and requirements that are standard across an industry are more likely to be supported in an off-the-shelf solution – and, therefore represent less risk than requirements that are peculiar to a business area. Naturally, more effort and detail will go into documenting the high-risk requirements.

I’ve tried to summarize some of this in a table that looks at UML tool usage for projects based on their size, solution type and lifecycle approach. In the table, a ‘small’ project is one that has a short timeline and budget and does not involve a change to a business process; an example is a change to an existing screen, or the addition of a new query screen to an existing system. An example of a large project , on the other hand, is the introduction of a new business product or service. The notes in the last column of the table relate to new UML artifacts; however, where there are existing UML artifacts related to the problem, they should be reviewed, and amended as required. The table can be applied to non-UML projects simply by replacing the UML terms in the last column as follows:

‘Business process models’ – instead of ‘business use cases’
‘User requirements/ user tasks’ – instead of ‘system use cases’
‘Statechart diagrams ‘– instead of ‘state-machine diagrams’
‘Data models/ERDs ‘– instead of ‘class diagrams’

Tailoring UML tools usage to the project:

Project Size: Small

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: May be skipped, as no changes made to business process. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping.[1] Class diagrams: Model new classes and relationships to discover structural business rules; may be skipped if problem well-understood. State-machine diagrams: May be skipped. Activity diagrams: May be skipped.
In-house development	Definitive	Business use cases: May be skipped, as no changes to business process.. System Use Cases: Complete Class diagrams: May be skipped if a simple change, such as query screen. However, if new business concepts introduced, model them and their relationships in order to discover structural business rules. State-machine diagrams: May be skipped Activity diagrams: Use as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	All lifecycles	Business use cases: May be skipped, as no changes to business process. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model new classes and relationships to discover structural business rules – focusing on business objects and rules that must be complied with but are not standard in the industry. (This step may be skipped when the problem is well understood and the rules are standardized.) State-machine diagrams: May be skipped. Activity diagrams: May be skipped.

¹ Agile projects may use ‘user stories’ as an alternative to use cases.

Project Size: Large

Solution type	Lifecycle	UML tools
In-house development	Empirical	Business use cases: Complete (or use a non-UML alternative) in order to capture end-to-end business process workflow. System Use Cases: List and name new use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be worked out through prototyping. Class diagrams: Complete. Classes, relationships and numerical rules (multiplicities) are required for across-the-board business rules. State-machine diagrams: Use to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
In-house development	Definitive	Business use cases: Complete. System Use Cases: Complete Class diagrams: Complete Activity diagrams: Use to describe workflow of business use cases (business processes) and as addendum for system use cases whose flows connect in complex ways.
Off-The-Shelf	Empirical	Business use cases (or a non-UML alternative): For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. State-machine diagrams: Create in order to analyze lifecycles of key business objects. Activity diagrams: Use to describe workflow of business use cases (business processes) and as part of user requirements, where flow is complex – for example, to indicate navigation through and between screens.
Off-The-Shelf	Definitive	Business use cases: For high-risk processes that are not standard in the industry. System Use Cases: List and name use cases and alternate flows. Provide only brief summaries of each flow, since interaction details will be differ based on the vendor. Class diagrams: Model classes and relationships to discover structural business rules that must be adhered to by vendor solution; focus on rules that are non-standard in the industry. Activity diagrams: Use to describe workflow of business use cases (business processes) focusing on processes that are non-standard in the industry. Use activity diagrams as an addendum for system use cases whose flows connect in complex ways.

Finally, keep in mind that we’re talking here only about the artifacts that are created for each project. Some of these will be directed to business stakeholders and some will only be distributed to other team members and solution providers. But that’s a topic for another column (and one that I address on a tool-by-tool basis in my book, The Business Analyst’s Handbook’).

In the meantime, I’m looking forward to having others weigh in on today’s question “How much analysis do you really need to do?”

Howard Podeswa
For more on this topic, please see The Business Analyst's Handbook and the upcoming release of UML for the IT Business Analyst, 2nd Edition

Talking with Ford’s Head of Social Media

Barton George — Thu, 09 Apr 2009 12:12:00 GMT

Last week I attended the Web 2.0 expo in San Francisco. In case you thought that social media was just for web 2.0 start-ups and teenagers, one of the cooler talks I saw was given by Scott Monty, the head of Ford Motor’s Social Media efforts. I was so intrigued that I thought I would grab him for an interview. He graciously agreed and here’s the result. Enjoy!

To watch in High Quality: after clicking play, click the “HQ” button that will appear on the bottom.

Some of the topics Scott tackles:

Ford’s goal of becoming one of the world’s leading social brands.
Setting content free.
Innovation is made up of small tweaks on existing platforms that build value over time.
How did Ford come to decide they needed a head of social media and how did they pick Scott.
The two things coming up that Scott is most excited about: the Fiesta Movement and the evolution of Fordstory.com into Ford’s social media hub.

BTW, If you want to follow Scott on Twitter, its @scottmonty.

Barton George
Sr. Director, Business Development, Blueprint process mapping tool
Lombardi Software

Learn about Blueprint and sign up for a 30 day free trial

Tablet UML

Adrian M. — Thu, 05 Jul 2007 02:41:00 GMT

In most of the projects and organizations I have worked for I have seen a very interesting pattern:

- Developers get developer specific tools such as MS Visual Studio.

- Testers get testing specific tools such as Mercury TestDirector.

- Analysts get MS Word, Excel, and PowerPoint. The more "progressive" organizations might provide their business analysts and systems analysts with Visio.

Wow... cool!

If you think I'm venting, you right? I am venting!

To tell you the truth: I don't get it!

There are so many great tools for requirements management and system modeling yet most organizations have not yet realized that spending a few bucks on tools for their analysts can actually improve productivity and save them money in the long run.

My gut feeling tells me that this problem is closely tied to the view of the business analyst. The business analysis, as a profession, it's just beginning to bud.

I'm hoping that, soon, most organizations will begin to realize the value that business analysts and systems analysts bring to the table. When that happens, the shortage of qualified analysts will be evident and companies will try to find other ways to increase productivity. An adequate tool is one such way!

But I digress...

What triggered these thoughts (again) was that I stumbled upon a UML tool for the Tablet PC called Tablet UML. While I have not used the product - it's a very intriguing idea. Imagine being in a JAD session or brainstorming meeting and, instead of pen & paper, using a tablet PC to capture the models being discussed.

Technologies and tools such as these are going to become more and more important and valuable as organizations realize the importance of analysts and attempt to find new ways to increase their productivity.

Business Analyst Community & Resources | Modern Analyst

How much analysis do you really need to do?

Talking with Ford’s Head of Social Media

Tablet UML